Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/dashpay/research/01-dip-spec.md`:
- Line 131: Several fenced code blocks use plain ``` without a language tag;
update each triple-backtick fence in the document (e.g., the blocks currently
shown as ``` at the indicated locations) to include an explicit language token
(for non-code or prose use `text`, or a specific language like `json`, `bash`,
`markdown` where applicable) so the markdown linter passes; search for all
occurrences of ``` (including the ones noted around 131, 194, 245, 289, 418,
455) and replace them with ```text or the appropriate language identifier.

In `@docs/dashpay/research/02-rust-dashcore-keywallet.md`:
- Line 232: The markdown contains fenced code blocks without language tags;
update the offending triple-backtick fences to include the appropriate language
identifier (e.g., ```rust, ```bash, or ```text) for the code snippets so
markdownlint passes and syntax highlighting works—locate the plain ``` fences in
the document (the blocks referenced in the review) and replace them with
language-tagged fences.

In `@docs/dashpay/research/05-swift-app.md`:
- Line 47: The fenced code block currently uses a bare triple-backtick fence
(```); add a language tag (e.g., ```swift or ```text) immediately after the
opening backticks to satisfy markdownlint and enable proper syntax highlighting
for that block.

In `@docs/dashpay/research/06-interop-desk-check.md`:
- Line 366: The fenced code block uses plain ``` without a language tag; update
the opening fence to include an appropriate language identifier (for example
`http`, `text`, or `bash`) so markdownlint is satisfied and readability
improves—locate the triple-backtick fenced block in the document and add the
language tag immediately after the opening ``` fence.
- Line 24: The table row contains an extra leading column ("2") so it has four
columns while the table header defines three; remove the extra column in the row
that contains "2" (the row with "ECDH shared-key derivation" and the
libsecp256k1 SHA256 expression) so the row matches the 3-column header layout,
keeping the description "ECDH shared-key derivation" and the verdict "**PASS** —
all three stacks compute libsecp256k1-style `SHA256((y[31]&0x1|0x2) ‖ x)`" as
the remaining columns.

In `@docs/dashpay/SPEC.md`:
- Line 111: Several fenced code blocks in SPEC.md are missing language
identifiers; update each triple-backtick fence (``` ) at the noted examples so
they include an appropriate language tag (e.g., change ``` to ```text, ```rust,
or ```swift as appropriate) to satisfy markdownlint and enable correct syntax
highlighting; search for the bare ``` occurrences (including the ones referenced
near the examples) and replace them with language-tagged fences, ensuring
opening and closing fences remain paired.

In `@packages/rs-platform-wallet/src/manager/dashpay_sync.rs`:
- Around line 221-223: The background loop cleanup currently unconditionally
sets this.background_cancel to None (in the block near start()), which can
overwrite a newer token if stop() and start() race; change the logic so the
background thread only clears background_cancel if the stored cancel token it
captured at spawn time still matches the current token in this.background_cancel
(i.e., capture the Arc/ID of the cancel handle when spawning and
compare-before-clearing); apply the same compare-and-clear pattern in the stop()
/ thread-exit cleanup (references: this.background_cancel, start(), stop()) so a
late-exiting old loop cannot null out a replacement token.

In `@packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs`:
- Around line 103-118: The sender/recipient key selection currently using
sender_identity.public_keys().iter().find(...) (checking Purpose::ENCRYPTION and
KeyType::ECDSA_SECP256K1) can pick a disabled/rotated key; update the logic to
only consider active/enabled keys (e.g., filter by .enabled() or reuse the
existing enabled-key selection utility used for signing) so
sender_encryption_key and recipient_key_index (the call to
select_recipient_key_index should be updated similarly or replaced) always
reference the current active ENCRYPTION/DECRYPTION ECDSA_SECP256K1 key; ensure
you still call .map(...).ok_or_else(...) and preserve error type
PlatformWalletError::InvalidIdentityData when no active key is found.
- Around line 516-556: collect_account_build_candidates currently skips contacts
when info.core_wallet.accounts.dashpay_external_accounts.contains_key(&key) is
true, which prevents retries if register_contact_account previously failed after
inserting an external entry; remove that gating so contacts with an
incoming_request (incoming.encrypted_public_key and key indices) are always
returned as AccountBuildCandidate (unless payment_channel_broken) to allow
build_contact_accounts -> register_contact_account to retry; specifically, in
collect_account_build_candidates remove or change the has_external
check/continue and rely on contact.incoming_request and payment_channel_broken
to decide inclusion (keep AccountBuildCandidate fields: contact_id,
encrypted_public_key, our_decryption_key_index, contact_encryption_key_index).
- Around line 452-509: parse_contact_request_doc currently only extracts
required fields and drops optional fields encryptedAccountLabel and
autoAcceptProof, causing restores to lose these values; update
parse_contact_request_doc (and thus parse_sent_contact_request_doc which calls
it) to also read props.get("encryptedAccountLabel").and_then(|v: &Value|
v.as_str()).map(|s| s.to_owned()) and props.get("autoAcceptProof").and_then(|v:
&Value| v.as_bytes()).cloned() (or appropriate conversions) and pass them into
ContactRequest::new (or the appropriate constructor/factory) so the
ContactRequest created preserves encryptedAccountLabel and autoAcceptProof
during ingest/reconcile. Ensure the match arm pattern includes these Option
values and the fallback logging remains unchanged.

In
`@packages/rs-platform-wallet/src/wallet/identity/state/managed_identity/contact_requests.rs`:
- Around line 116-130: The code removes an incoming request from
self.incoming_contact_requests but the returned ContactChangeSet only records
cs.rejected, so on replay the incoming entry isn't removed; update the change
set returned by the function to also include the incoming-removal for (owner_id,
*sender_id, account_reference) (i.e., add the corresponding removal entry to the
ContactChangeSet alongside cs.rejected) so that replay will delete the
incoming_contact_requests entry when applying the rejection tombstone.

---

Outside diff comments:
In `@packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs`:
- Around line 806-875: The local-only already_reciprocated check (variable
already_reciprocated) can be stale; change the flow so before attempting
send_contact_request_with_external_signer you either (A) perform a platform
check for an existing reciprocal contact request/relationship (use whatever
network client/query you have for checking platform contact requests for
(ownerId,toUserId,accountReference)) and set already_reciprocated accordingly,
or (B) keep the existing local check but add a duplicate-send fallback: catch
the unique-index conflict/error returned by
send_contact_request_with_external_signer and, on that specific error, log that
the reciprocal exists on Platform and run the adopt path (call
register_contact_account(&our_identity_id, &sender_id, 0) and treat as success).
Reference already_reciprocated, send_contact_request_with_external_signer, and
register_contact_account when implementing either fix.

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet-storage/migrations/V001__initial.rs`:
- [BLOCKING] packages/rs-platform-wallet-storage/migrations/V001__initial.rs:186-213: V001 migration edited in-place violates append-only policy and breaks upgrade from v4.0.0-beta.4
  This PR adds `contacts.payment_channel_broken` and a new `rejected_contact_requests` table by editing V001 directly. V001 (without these additions) was already shipped in `v4.0.0-beta.4` (commit da9d3fe84e / schema confirmed via `git show`), and `packages/rs-platform-wallet-storage/README.md:106` explicitly states migrations are append-only and applied by refinery on every `open`. refinery checksums each migration in `refinery_schema_history`; against an existing v4.0.0-beta.4 DB it will either abort with a divergent-checksum error or silently skip V001 (already applied) — in which case neither the new table nor the new column is ever created, and the first runtime write in `contacts.rs:240` (`INSERT INTO rejected_contact_requests …`) or `contacts.rs:194-212` (`payment_channel_broken` column) fails at the SQLite layer. `tc029_migration_fingerprint_stable` does not catch this because it only checks self-stability, not a pinned hash. Add `V002__dashpay_reject_and_broken_channel.rs` doing `ALTER TABLE contacts ADD COLUMN payment_channel_broken INTEGER` and `CREATE TABLE rejected_contact_requests (…)`; the loader at `contacts.rs::load_state` already tolerates NULL `payment_channel_broken`, so a default-less ALTER is compatible.

In `packages/rs-platform-wallet/src/wallet/identity/state/managed_identity/contact_requests.rs`:
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/state/managed_identity/contact_requests.rs:109-131: `record_rejected_contact_request` removes incoming in memory but does not emit `removed_incoming`
  The function calls `self.incoming_contact_requests.remove(sender_id)` and returns a `ContactChangeSet` populated only with `cs.rejected`. The unified-`contacts`-table writer at `rs-platform-wallet-storage/src/sqlite/schema/contacts.rs:182-193` only `DELETE`s when `cs.removed_incoming` is non-empty, so the previously persisted state='received' row (with the `incoming_request` blob) stays in SQLite. Once `persister.load()` (TODO at `sqlite/persister.rs:909`) is wired up, the unified contacts reader rebuckets that row as an incoming request, `apply_changeset` re-inserts it into `incoming_contact_requests`, and the FFI surfaces the explicitly-rejected request back to the UI. The persisted delta is also internally inconsistent with the in-memory mutation — a delta-persistence invariant violation. The in-memory `rejected_tombstone_round_trips_and_respects_account_reference` test does not catch this because it round-trips via `apply_changeset`, not the SQLite reader. Fix by also inserting a matching `ReceivedContactRequestKey { owner_id, sender_id: *sender_id }` into `cs.removed_incoming`.

In `packages/rs-platform-wallet-storage/src/sqlite/schema/identities.rs`:
- [BLOCKING] packages/rs-platform-wallet-storage/src/sqlite/schema/identities.rs:206-222: `rejected_contact_requests` is written but never read — tombstones lost across restart
  The PR adds a writer (`contacts.rs:240`), a migration row (`V001__initial.rs:203`), and an `apply_changeset` branch that restores `ManagedIdentity.rejected_contact_requests` from `cs.rejected`. But `managed_identity_from_entry` hard-codes `rejected_contact_requests: Default::default()` (line 214), and grep confirms no `load_state` reader for the new table. Once `persister.load()` (TODO at `sqlite/persister.rs:909`) is wired up, the in-memory tombstone map is always empty after restart even though SQLite holds the rows. `is_request_rejected` then returns `false`, the sweep's tombstone-skip in `network/contact_requests.rs:396-404` does not fire, and the recurring DashPay loop (G12) resurrects every rejected request on the first sweep — exactly the M1 failure mode the SPEC.md cites as the reason G5 must land with G12. Add a per-wallet `load_state` for `rejected_contact_requests` and route its output into the `ContactChangeSet.rejected` synthesized during rehydration.

In `packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs`:
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:711-728: Transient identity fetch failures inside account-build are marked as permanent
  `build_contact_accounts` treats any error from `register_external_contact_account` as permanent and calls `mark_contact_channel_broken`. But `register_external_contact_account` (`network/contacts.rs:400-407`) performs another `Identity::fetch` for the same contact and wraps the DAPI/network error as `PlatformWalletError::InvalidIdentityData`. A transient DAPI hiccup after validation therefore permanently disables the payment channel; subsequent sweeps skip the contact via the `payment_channel_broken` filter at line 530, and recovery only fires if a superseding contactRequest happens to arrive — contradicting the policy in the docstring at lines 573-578 ("Transient (identity fetch / network): logged, left for the next sweep to retry. The broken flag stays clear."). The fix is to perform the contact-identity fetch and treat its failure as transient *before* calling `register_external_contact_account` (mirroring the existing fetch at lines 631-655) and to scope the permanent-broken classification to genuinely non-recoverable failures (decrypt/decode, missing-key, key-type mismatch).
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:383-392: Superseding requests from established contacts are skipped — `payment_channel_broken` recovery is unreachable
  The received-side ingest drops every doc whose sender is already in `established_contacts` before consulting `accountReference`. `EstablishedContact::reestablish_preserving_metadata` exists precisely to clear `payment_channel_broken = false` when a fresh request flows in (see `types/dashpay/established_contact.rs:84-104`), and `collect_account_build_candidates` documents the recovery contract at lines 528-529 ("never retry a permanently-broken channel — wait for a superseding request (which clears the flag on re-establish)"). But there is no path that reaches `reestablish_preserving_metadata` for an already-established sender from the sync sweep — `add_incoming_contact_request` is only called for new senders here, and the send-side guard at `state/managed_identity/contact_requests.rs:46-48` similarly returns early for established contacts. Net effect: once `payment_channel_broken` is set, it stays set forever. Either (a) detect a superseding incoming request (new `accountReference` for the same sender) and route it through the reestablish path, or (b) change the broken-channel policy so the next sweep can retry under controlled conditions.
- [SUGGESTION] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:5733-5749: `select_recipient_key_index` returns disabled keys
  The send-side recipient-key selector iterates `recipient_identity.public_keys()` and returns the first key whose purpose is DECRYPTION (then ENCRYPTION) and whose type is ECDSA_SECP256K1, with no `disabled_at` check. `validate_contact_request` in `crypto/validation.rs` does gate on disabled keys, so if a preferred DECRYPTION key has been rotated/disabled this selector returns it anyway and the broadcast fails downstream with an opaque error instead of falling through to a usable ENCRYPTION key on the same identity. Add `&& k.disabled_at().is_none()` to both branches so selection is consistent with validation.

In `packages/rs-platform-wallet/src/wallet/identity/crypto/validation.rs`:
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/crypto/validation.rs:50-62: `purpose_mismatch` is set even when a non-purpose hard error is also present
  The docstring at lines 19-29 contracts `purpose_mismatch` as `true` *only* when the sole reason for invalidity is a key-purpose mismatch — it is what tells `build_contact_accounts` at `network/contact_requests.rs:689` to treat the failure as a non-permanent skip instead of marking the channel permanently broken. The implementation does not preserve that invariant: `add_purpose_error` unconditionally sets `purpose_mismatch = true`, and `add_error` never clears it. A request whose key has both a wrong key type (hard, permanent error) and a wrong purpose ends up with `is_valid = false, purpose_mismatch = true`, and the caller skips + retries forever instead of marking broken. The mobile testnet census makes this rare in practice today, but the classifier is the load-bearing primitive the recovery policy is built on — fix `add_error` to clear the flag, and fix `add_purpose_error` to only set it if no prior hard error was recorded.

In `packages/rs-platform-wallet/src/manager/dashpay_sync.rs`:
- [SUGGESTION] packages/rs-platform-wallet/src/manager/dashpay_sync.rs:192-227: `stop()` followed quickly by `start()` can let the old thread null out the new cancel token
  `stop()` takes the current `background_cancel`, sets it to `None`, then cancels the old token. The spawned thread exits its loop on cancellation and at lines 221-223 re-acquires the guard and writes `*guard = None`. If `start()` runs between `stop()` and the old thread's cleanup block, the old thread's final clear will overwrite the new token just installed by `start()` — leaving `background_cancel` empty while a fresh sync thread is still running, so a subsequent `stop()`/`quiesce()` will be a no-op against that running thread. The normal shutdown path (`quiesce` waits for in-flight passes) does not hit this, but bare `stop()`/`start()` races can. Fix by capturing the token at spawn time and only clearing the guard if it still holds that same token (`if matches!(*guard, Some(t) if Arc::ptr_eq(...)) { *guard = None; }`).

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletPersistenceHandler.swift`:
- Around line 1919-1925: persistDashpayPayments is swallowing failures from
backgroundContext.save() via try?, which can silently drop payment-history
updates; change the save to propagate or log errors instead of ignoring them:
replace the try? backgroundContext.save() with a throwing or do/catch path
inside persistDashpayPayments that captures the thrown error from
backgroundContext.save(), records telemetry/logging (or rethrows to the caller)
with context (e.g., include which payment batch or wallet ID), and preserve the
existing inChangeset check (if !self.inChangeset) so the save still only runs
when appropriate; update callers or function signature as needed to handle
propagated errors or ensure telemetry is emitted in the catch.

In
`@packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/DashPay/DashPayTabView.swift`:
- Around line 35-40: The optimisticSentIds and ownProfile state are
identity-scoped but currently persist across identity switches; update the
activeIdentity handling (the Task that observes activeIdentity) to reset
identity-scoped UI state at the start of the task: clear optimisticSentIds and
set ownProfile to nil (or otherwise remove cached profile) before loading;
alternatively refactor optimisticSentIds and ownProfile to be keyed by owner
identity (e.g., a dictionary keyed by activeIdentity.id) and read/write via that
key, and ensure loadOwnProfileFromCache() does not retain the previous profile
on read failure for the new identity but returns nil so the UI doesn’t show the
old identity’s data.

In
`@packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/IdentityDetailView.swift`:
- Around line 1235-1243: The avatar downloader currently accepts any parseable
URL, allowing non-HTTPS schemes; update fetchAvatarBytes to explicitly validate
the URL scheme and reject anything not exactly "https" before creating the
URLRequest, returning an error (or nil) for non-https inputs; locate
fetchAvatarBytes (and the analogous implementation referenced around lines
1390-1410) and add a guard that checks url.scheme?.lowercased() == "https" and
fails early with a clear error to prevent http or other schemes from being
fetched.

In
`@packages/swift-sdk/SwiftExampleApp/SwiftExampleAppUITests/DashPayTabUITests.swift`:
- Around line 92-97: Replace the immediate existence check on the toolbar
refresh button with a timed wait to avoid flakes: locate the `refresh` query
using `Identifier.refreshButton` in DashPayTabUITests (variable `refresh`) and
change the assertion to call `refresh.waitForExistence(timeout: ...)` instead of
checking `refresh.exists`, keeping the same failure message; choose a reasonable
timeout (e.g., 1–5s) consistent with other tests.

---

Nitpick comments:
In
`@packages/swift-sdk/SwiftTests/SwiftDashSDKTests/DashPayPersistenceTests.swift`:
- Around line 421-465: In testPaymentRefreshDoesNotCommitAnOpenChangesetRound,
add assertions that verify the payment row staged by persistDashpayPayments is
not visible mid-round and is rolled back after endChangeset(..., success:
false); specifically, call the existing payment-fetch helper (or add/rename a
fetch function for PersistentDashpayPayment rows) to assert count == 0
immediately after the mid-round persist and again after
handler.endChangeset(..., success: false), mirroring the contact-row assertions
so the test verifies payment atomicity as well as contact atomicity.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Core/Views/AccountListView.swift`:
- Around line 35-42: The visible-empty-state logic is still checking the raw
accounts collection instead of the filtered/sorted list, causing the UI to hide
the "No Accounts" state when only accountType 12/13 are present; update the
empty-state checks to use orderedAccounts.isEmpty (or introduce a
visibleAccounts computed collection that filters out accountType 12/13 and reuse
it everywhere) and replace any usages of accounts.isEmpty / !accounts.isEmpty in
AccountListView with checks against that filtered collection so the UI matches
the displayed list (keep AccountListView.sortKey as the sorting helper).

---

Outside diff comments:
In
`@packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/DashPay/DashPayTabView.swift`:
- Around line 23-26: The persisted AppStorage key stored in DashPayTabView
(`@AppStorage("dashpay.activeIdentityId") private var storedIdentityId`) is
global across networks; change it to be network-scoped by deriving the key from
the current network identifier (e.g., include network.rawValue or chainId) so
each network has its own stored key. Update DashPayTabView to compute the
AppStorage key at runtime (or use a computed property / wrapper that returns
"dashpay.activeIdentityId.\(networkId)") using the view’s network/environment
value and ensure storedIdentityId is read/written through that network-scoped
key so switching networks preserves separate selections.

---

Duplicate comments:
In
`@packages/swift-sdk/SwiftExampleApp/SwiftExampleApp/Views/DashPay/DashPayTabView.swift`:
- Around line 169-177: The task block keyed by .task(id:
activeIdentity?.identityId) is not resetting identity-scoped state: clear
optimisticSentIds and ownProfile immediately at the top of that task before
calling loadOwnProfileFromCache() and walletManager.dashPaySyncNow(); and update
loadOwnProfileFromCache() so that on a cache read failure for the new identity
it does not retain the previous ownProfile (set ownProfile to nil or replace
with an empty/default value) instead of keeping the old profile. Ensure the
reset refers to the existing properties optimisticSentIds and ownProfile and the
loadOwnProfileFromCache() function so the UI doesn't show the previous identity
while the new identity's cache is loaded.

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet-storage/src/sqlite/schema/identities.rs`:
- [BLOCKING] packages/rs-platform-wallet-storage/src/sqlite/schema/identities.rs:206-222: rejected_contact_requests is written but never read — tombstones lost across restart
  Verified at HEAD: managed_identity_from_entry still hard-codes rejected_contact_requests: Default::default() at line 214. The writer at contacts.rs:240 (INSERT INTO rejected_contact_requests) and migration row at V001:203 exist, but there is no load_state reader for the new table and apply_changeset only handles live deltas — restored state is always empty. The recurring DashPay loop's tombstone-skip at network/contact_requests.rs:396-404 never fires after a restart, so a rejected contact request is resurrected on the first sweep. Add a per-wallet load_state for rejected_contact_requests and route its output into the ContactChangeSet.rejected synthesized during rehydration.

In `packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletPersistenceHandler.swift`:
- [BLOCKING] packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletPersistenceHandler.swift:2980-2996: Wallet deletion omits new DashPay payment children before deleting identities — same fatal pattern as contact requests
  Verified: PersistentDashpayPayment.owner is declared as non-optional (`public var owner: PersistentIdentity`), and the new cascade relationship was added on PersistentIdentity.dashpayPayments in the M2 delta. The PHASE 1 pre-delete loop at lines 2986-2996 iterates dpnsNames, dashpayProfile, and contactRequests — but not dashpayPayments. The surrounding comment (lines 2962-2978) explicitly states this phase exists because SwiftData fatals during save() when it must null out a non-optional inverse on a child processed in the same delete batch. dashpayPayments has the exact same shape as contactRequests, so a wallet with persisted DashPay payments can crash or fail to wipe cleanly when deleted. Add a `for payment in Array(identity.dashpayPayments) { backgroundContext.delete(payment) }` loop alongside the existing pre-deletion.

In `packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs`:
- [SUGGESTION] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:245-261: select_recipient_key_index returns disabled keys
  Verified at HEAD lines 245-261: the selector iterates recipient_identity.public_keys() and returns the first DECRYPTION (then ENCRYPTION) ECDSA_SECP256K1 key with no disabled_at check. validate_contact_request in crypto/validation.rs does gate on disabled keys, so a recipient with a disabled preferred DECRYPTION key gets returned anyway and the broadcast fails downstream with an opaque error instead of falling through to a usable ENCRYPTION key on the same identity. Beyond reliability, on the send-side this also means the wallet could encrypt the DIP-15 compact xpub to a revoked key whose private half may be compromised. Add `&& k.disabled_at().is_none()` to both branches so selection matches validation.

In `packages/rs-platform-wallet-ffi/src/dashpay_payment.rs`:
- [SUGGESTION] packages/rs-platform-wallet-ffi/src/dashpay_payment.rs:89-108: DashpayPaymentFFI derives Clone, Copy despite owning *mut c_char strings reclaimed by dashpay_payment_array_free
  Verified at HEAD lines 89-108: DashpayPaymentFFI carries two heap-owned C strings (txid, memo — produced via CString::into_raw in cstring_or_null and reclaimed via CString::from_raw in dashpay_payment_array_free), yet the struct is `#[derive(Debug, Clone, Copy)]`. With Copy the compiler will silently shallow-duplicate the struct on any by-value rebinding inside this crate, and a subsequent free walk on the array (or a stray from_raw on the duplicate) would double-free the txid/memo allocations across the FFI boundary. Today's call sites are sound — the struct is built once, moved into Vec → Box<[T]> → Box::into_raw, and reclaimed exactly once — but the Copy derive removes the borrow-checker guardrail that normally prevents this class of bug at refactor time. Sibling FFI types in this crate that own heap pointers (ContactRequestFFI, WalletChangeSetFFI) deliberately omit Copy for exactly this reason. Drop Copy (and Clone if unneeded) on this struct. The cross-boundary contract is unchanged — Swift consumes by raw pointer.

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet/src/wallet/identity/state/managed_identity/contact_requests.rs`:
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/state/managed_identity/contact_requests.rs:109-131: record_rejected_contact_request drops incoming in memory but never persists the deletion
  Verified at HEAD lines 109-131: line 116 calls `self.incoming_contact_requests.remove(sender_id)` but the returned `ContactChangeSet` (lines 127-129) only populates `cs.rejected`. The unified contacts-table writer in `rs-platform-wallet-storage/src/sqlite/schema/contacts.rs` only DELETEs incoming rows when `cs.removed_incoming` is non-empty, so the persisted `state='received'` row with its stale `incoming_request` blob stays in SQLite. Once `persister.load()` is wired up, the contacts reader re-buckets that row as an incoming request and `apply_changeset` re-inserts it — the explicitly-rejected request reappears in the UI. The in-memory mutation and the persisted delta are internally inconsistent. Emit a matching `ReceivedContactRequestKey { owner_id, sender_id: *sender_id }` into `cs.removed_incoming` alongside `cs.rejected`.

In `packages/rs-platform-wallet-storage/src/sqlite/schema/identities.rs`:
- [BLOCKING] packages/rs-platform-wallet-storage/src/sqlite/schema/identities.rs:206-222: rejected_contact_requests tombstones are written but never restored on rehydration
  Verified at HEAD: `managed_identity_from_entry` still hard-codes `rejected_contact_requests: Default::default()` at line 214. The writer at `contacts.rs:240` (`INSERT INTO rejected_contact_requests`) and the migration row at `V001:203` exist, but no `load_state` reader for the new table exists, and `apply_changeset` only handles live deltas — restored state is always empty. The recurring DashPay loop's tombstone-skip at `network/contact_requests.rs:396-404` therefore never fires after a restart, so a rejected contact request is resurrected on the first sweep and surfaces to the user again. Security framing: the on-platform document is immutable, so the local tombstone is the ONLY thing that suppresses a spammer's repeated contact request — a wipe-on-restart defeats the user's explicit reject. Add a per-wallet `load_state` reader for `rejected_contact_requests` and route its output into the `ContactChangeSet.rejected` synthesized during rehydration.

In `packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs`:
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:711-729: Transient DAPI failures inside register_external_contact_account are classified as permanent
  Verified at HEAD lines 711-729: `build_contact_accounts` treats ANY error from `register_external_contact_account` as permanent and calls `mark_contact_channel_broken`. `register_external_contact_account` performs a fresh `Identity::fetch` internally and wraps DAPI/network failures as `PlatformWalletError::InvalidIdentityData`. A single transient DAPI hiccup therefore permanently disables the payment channel; subsequent sweeps skip the contact via the `payment_channel_broken` filter, and recovery only fires if a superseding contactRequest arrives — but the established-contact ingest skip at line 389 makes that path unreachable. Combined, a transient network event bricks a channel forever, and a malicious or unreliable DAPI endpoint becomes a persistent availability attack against payments to a specific contact. Fix by either passing the pre-fetched identity into registration or scoping permanent-broken classification to genuinely non-recoverable failures (decrypt/decode, missing-key, key-type mismatch).
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:383-404: Established-contact ingest skip makes payment_channel_broken recovery unreachable
  Verified at HEAD lines 383-404: the received-side ingest drops every doc whose sender is already in `established_contacts` (line 389) BEFORE consulting `accountReference`. `EstablishedContact::reestablish_preserving_metadata` exists precisely to clear `payment_channel_broken` when a fresh request flows in, and `collect_account_build_candidates` documents the recovery contract ("never retry a permanently-broken channel — wait for a superseding request which clears the flag on re-establish"). But no path reaches `reestablish_preserving_metadata` for an already-established sender from the sync sweep — `add_incoming_contact_request` is only called for new senders here, and the send-side guard at `state/managed_identity/contact_requests.rs:46-48` also returns early for established contacts. Once `payment_channel_broken` is set, it stays set forever. Either detect a new `accountReference` for the same sender and route through the reestablish path, or change the broken-channel policy to permit controlled retry.
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:245-261: select_recipient_key_index returns disabled (revoked) keys — DIP-15 compact xpub encrypted to a key whose private half may be compromised
  Verified at HEAD lines 245-261: the selector iterates `recipient_identity.public_keys()` and returns the first DECRYPTION (then ENCRYPTION) ECDSA_SECP256K1 key with no `disabled_at` check. `validate_contact_request` in `crypto/validation.rs` does gate on `disabled_at`, so the asymmetry creates both a reliability bug (an opaque downstream broadcast failure instead of falling through to a usable key) AND a real confidentiality exposure: on send, the wallet encrypts the 69-byte DIP-15 compact xpub (fingerprint‖chaincode‖pubkey — combined with `accountReference` lets the holder derive every receiving address on that account) to a key the recipient has explicitly revoked. Identity-key revocation is the on-platform mechanism for declaring "the private half of this key may be compromised". Add `&& k.disabled_at().is_none()` to both branches so selection matches validation. (Promoted from suggestion to blocking on the security-auditor confidentiality analysis.)

In `packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletPersistenceHandler.swift`:
- [BLOCKING] packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletPersistenceHandler.swift:3018-3035: Wallet deletion PHASE 1 omits PersistentDashpayPayment children — same fatal pattern as contactRequests
  Verified at HEAD: PHASE 1 (lines 3024-3034) iterates `dpnsNames`, `dashpayProfile`, and `contactRequests` but NOT `dashpayPayments`. `PersistentDashpayPayment.owner` is non-optional (`PersistentDashpayPayment.swift:98`), and `PersistentIdentity.dashpayPayments` is the cascading inverse added in this PR. The surrounding comment (lines 3018-3023) explicitly states this phase exists because SwiftData fatals during `save()` when it must null out a non-optional inverse on a child processed in the same batch — exactly the shape of the new payments relationship. A wallet with persisted DashPay payment history will hit the SwiftData fatal at PHASE 2 (`save()` after `delete(identity)`), aborting before the wallet row is removed. The user's belief that they wiped DashPay data is wrong, and plaintext memo + counterparty id + amount + txid rows remain on disk. Add a `for payment in Array(identity.dashpayPayments) { backgroundContext.delete(payment) }` loop alongside the existing pre-deletions.

In `packages/rs-platform-wallet/src/manager/dashpay_sync.rs`:
- [BLOCKING] packages/rs-platform-wallet/src/manager/dashpay_sync.rs:192-235: DashPaySyncManager thread cleanup unconditionally clears the cancel token — stop/start race enables use-after-free across FFI
  Verified at HEAD lines 192-235: the spawned thread's cleanup at lines 230-232 writes `*guard = None` on loop exit regardless of which token the slot currently holds. If `stop()` cancels the old token and `start()` installs a fresh token before the old thread reaches cleanup, the old thread clears the NEW token — `background_cancel` is empty while a fresh sync thread is still running. `stop()`/`quiesce()` then become a no-op against that running thread. In this PR's Swift integration the persister and DashPay event callbacks close over an UnsafePointer<Context> allocated on the Swift side; calling `dashpay_sync_manager_destroy` (or the wallet manager's drop) after the visible token was cleared frees that context while the surviving thread continues invoking the callbacks against the freed pointer — a concrete use-after-free crossing the C ABI, reachable through normal start/stop/destroy controls (toggling tabs, login/logout) and widened by attacker-influenced network timing. Capture the spawned token and only clear the slot if it still holds the same token (`Arc::ptr_eq`), mirroring `ShieldedSyncManager`'s generation guard. (Upgraded from suggestion to blocking based on the security-auditor and codex-security cross-checks of the destroy/UAF path.)

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs`:
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:165-201: Send-side rotation version lookup ignores established_contacts — re-send after auto-establishment reuses version=0 and collides on the unique index
  The new G3 rotation logic computes `previous_version` only from `managed.sent_contact_requests.get(recipient_identity_id)` (line 171). But establishment (`add_incoming_contact_request` line 175 and `apply_established_contact` line 372 in state/managed_identity/contact_requests.rs) explicitly removes the entry from `sent_contact_requests` and parks the prior outgoing request on `EstablishedContact.outgoing_request`. Once the reciprocal arrives and a sweep auto-establishes the pair, the next `send_contact_request` to that recipient sees `previous_version = None` and falls back to `version = 0`. With deterministic xpub/ECDH for the same (sender, recipient) and unchanged `account_index`, the PRF reproduces the same masked `account_reference` as the original sent request. The contract's unique index `($ownerId, toUserId, accountReference)` rejects the broadcast — the exact failure mode G3 was added to prevent. Fall back to `established_contacts[recipient].outgoing_request` (taking the max of both versions if both are present).
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:441-478: Historical contactRequest documents replay as fresh rotations every sync sweep
  The rotation guard at line 451 only compares the incoming reference against the currently tracked reference (incoming map or established contact). contactRequest documents are immutable, and `fetch_received_contact_requests(identity_id, None)` (line 370) is unfiltered, so every sweep returns both the original v=0 and any rotated v=N documents. Within a single sweep, ingesting v=0 against an already-tracked v=N flips the established contact back to v=0 and queues a teardown (lines 472-478, then 517-528), and the next document in the same iteration flips it forward again. Across sweeps the same churn replays — the external account is torn down and rebuilt on every cycle, generating wasted DAPI traffic. Worse, if the freshest document falls outside the eventual paginated window (post-M3 growth), the contact can regress to the stale xpub. Compare by `created_at`/version monotonicity, not bare reference inequality: only apply rotation when the incoming request strictly supersedes the tracked one.
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:292-308: select_recipient_key_index returns disabled (revoked) keys — DIP-15 compact xpub encrypted to a key whose private half may be compromised
  Verified at HEAD lines 292-308: the selector iterates `recipient_identity.public_keys()` and returns the first DECRYPTION (then ENCRYPTION) ECDSA_SECP256K1 key with no `disabled_at` check. `validate_contact_request` does gate on `disabled_at`, so the send/receive interop rules are asymmetric. On send, the 69-byte DIP-15 compact xpub (fingerprint‖chaincode‖pubkey — combined with `accountReference` lets the holder derive every receiving address on that account) is encrypted to a key the recipient has explicitly revoked. Identity-key revocation is the on-platform mechanism for declaring 'this key's private half may be compromised'. Add `&& k.disabled_at().is_none()` to both branches so selection matches validation.

In `packages/rs-platform-wallet-storage/src/sqlite/schema/identities.rs`:
- [BLOCKING] packages/rs-platform-wallet-storage/src/sqlite/schema/identities.rs:206-222: rejected_contact_requests tombstones are written but never restored on rehydration
  `managed_identity_from_entry` still hard-codes `rejected_contact_requests: Default::default()` at line 214. The writer at `sqlite/schema/contacts.rs:240` (INSERT INTO rejected_contact_requests) and the V001 row exist, but there is no `load_state` reader for the new table, and `apply_changeset` only handles live deltas — restored state is always empty after restart. The recurring DashPay loop's tombstone-skip at `network/contact_requests.rs:457` therefore never fires after restart, so a rejected request is resurrected on the first sweep. Because the on-platform document is immutable, wiping the tombstone on restart defeats the user's explicit reject. Add a per-wallet `load_state` reader for `rejected_contact_requests` and route its output into the rehydration changeset / ManagedIdentity field.

In `packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletPersistenceHandler.swift`:
- [BLOCKING] packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletPersistenceHandler.swift:3024-3034: Wallet deletion PHASE 1 omits PersistentDashpayPayment children — same fatal pattern as contactRequests
  PHASE 1 iterates `dpnsNames`, `dashpayProfile`, and `contactRequests` but NOT `dashpayPayments`. `PersistentDashpayPayment.owner` is non-optional and `PersistentIdentity.dashpayPayments` is the cascading inverse added in this PR. The surrounding comment (lines 3008-3023) explicitly documents that this phase exists because SwiftData fatals during `save()` when it must null out a non-optional inverse on a child processed in the same batch — exactly the shape of the new payments relationship. A wallet with persisted DashPay payment history will hit the SwiftData fatal at PHASE 2 `save()`, aborting before the wallet row is removed. The user believes their data was wiped; plaintext memo + counterparty id + amount + txid rows remain on disk. Pre-delete `identity.dashpayPayments` alongside the other children.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/dashpay/research/07-contactinfo-conventions.md`:
- Around line 25-28: The fenced code block showing the derivation paths lacks a
language tag; update the triple-backtick fence surrounding the lines starting
with "encToUserId key:" and "privateData key:" to include a plain text specifier
(e.g., ```text or ```plaintext) so the block is lint-compliant and renders
correctly.

In `@packages/rs-platform-wallet-ffi/src/contact_info.rs`:
- Around line 51-56: The code currently converts signer_handle to usize and back
to a pointer which can lose pointer provenance; instead capture a typed pointer
to VTableSigner before the worker hop and then unsafely dereference it inside
the closure. Concretely, in the block that calls
PLATFORM_WALLET_STORAGE.with_item and block_on_worker, replace the
signer_addr/usize roundtrip with a typed pointer (e.g., signer_ptr of type
*const VTableSigner derived from signer_handle) and inside the async closure
obtain the signer with unsafe { &*signer_ptr } when creating the &VTableSigner
used by the worker; leave block_on_worker and wallet access unchanged. Ensure
the symbol names referenced are signer_handle, signer_ptr, VTableSigner,
PLATFORM_WALLET_STORAGE.with_item, and block_on_worker.

---

Duplicate comments:
In
`@packages/rs-platform-wallet/src/wallet/identity/state/managed_identity/contact_requests.rs`:
- Around line 109-130: In record_rejected_contact_request, after removing the
entry from incoming_contact_requests you must also record that removal in the
returned ContactChangeSet so the delta persists deletion; build a
ReceivedContactRequestKey (owner_id, *sender_id, account_reference) and insert
it into cs.removed_incoming before returning. This ensures the rejection
tombstone is added to cs.rejected and the corresponding incoming entry is
emitted via cs.removed_incoming for proper replay; locate
record_rejected_contact_request, incoming_contact_requests, ContactChangeSet and
Removed/removed_incoming to implement the insertion.

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet-storage/src/sqlite/schema/identities.rs`:
- [BLOCKING] packages/rs-platform-wallet-storage/src/sqlite/schema/identities.rs:206-222: rejected_contact_requests tombstones are written but never restored on rehydration
  Verified at HEAD: `managed_identity_from_entry` hard-codes `rejected_contact_requests: Default::default()` at line 214. The writer (INSERT INTO rejected_contact_requests) and the V001 row exist, but no `load_state` reader for the new table exists, and `apply_changeset` only handles live deltas — restored state is always empty after restart. The recurring DashPay loop's tombstone check at `network/contact_requests.rs:457` therefore never fires after a restart, so a rejected request is resurrected on the first sweep. Add a per-wallet `load_state` reader for `rejected_contact_requests` and route its output into the rehydrated `ManagedIdentity.rejected_contact_requests`.

In `packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletPersistenceHandler.swift`:
- [BLOCKING] packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletPersistenceHandler.swift:3024-3034: Wallet deletion PHASE 1 omits PersistentDashpayPayment children — same fatal pattern as contactRequests
  Verified at HEAD lines 3024-3034: PHASE 1 iterates `dpnsNames`, `dashpayProfile`, and `contactRequests` but NOT `dashpayPayments`. `PersistentDashpayPayment.owner` is non-optional and `PersistentIdentity.dashpayPayments` is the cascading inverse added in this PR. The surrounding comment (lines 3005-3023) explicitly documents that this phase exists because SwiftData fatals during `save()` when it must null out a non-optional inverse on a child processed in the same batch — exactly the shape of the new payments relationship. A wallet with persisted DashPay payment history will hit the SwiftData fatal at PHASE 2 `save()`, aborting before the wallet row is removed. The user believes their data was wiped; plaintext memo + counterparty id + amount + txid rows remain on disk — a confidentiality regression for users handing off or disposing devices.

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs`:
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:167-180: Send-side rotation ignores established contacts
  The resend path still derives `previous_version` only from `managed.sent_contact_requests`. Once reciprocal sync establishes the contact, that sent request is moved to `EstablishedContact.outgoing_request`, so a later send to the same recipient falls back to version 0. With the same sender, recipient, xpub, and account index, that can reproduce the original masked `accountReference` and collide with the DashPay contract unique index instead of creating a broadcastable rotation. The new load path also restores established contacts without repopulating `sent_contact_requests`, so a resend after relaunch hits the same state immediately.
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:441-478: Historical requests replay as rotations
  The receive-side rotation guard still compares only the incoming `accountReference` against the currently tracked reference. Because `fetch_received_contact_requests(identity_id, None)` is unfiltered and contactRequest documents are immutable, older v0 documents can be seen after a newer rotated document has advanced local state. Reprocessing the stale document as a rotation can replace the tracked request, tear down the external account, and then flip forward again on a later document or sweep; rotation acceptance needs a monotonic freshness check such as created time or decoded version, not bare reference inequality.
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:806-826: Transient account-registration failures become permanent
  `build_contact_accounts` still treats every `register_external_contact_account` error as permanent and marks `payment_channel_broken`. That callee performs additional network-backed identity/decryption work, so a transient DAPI or fetch failure can be converted into durable local broken-channel state. Future sweeps then skip the contact until the other party sends a superseding request; only genuinely non-recoverable decrypt, decode, missing-key, or key-type failures should take the permanent-broken path.
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/network/contact_requests.rs:292-308: Disabled encryption keys are still selectable
  `select_recipient_key_index` still chooses the first DECRYPTION or ENCRYPTION ECDSA_SECP256K1 key without checking `disabled_at`, while receive-side validation rejects disabled keys. A sender can therefore encrypt the DIP-15 compact xpub to a key the recipient has revoked on-chain, which is the signal that the private half may be compromised. The same missing disabled-key filter remains in the contactInfo root encryption key selector at `contact_info.rs:313-320`, allowing owner-private alias/note/hidden metadata to be published under a revoked encryption key id.

In `packages/rs-platform-wallet-storage/migrations/V001__initial.rs`:
- [BLOCKING] packages/rs-platform-wallet-storage/migrations/V001__initial.rs:178-212: V001 was edited in place
  `contacts.payment_channel_broken` and the `rejected_contact_requests` table are still added directly to V001, and there is no V002 migration. V001 already shipped, so existing v4.0.0-beta.4 databases will either fail refinery checksum validation or treat the old V001 as already applied and never create the new column/table. Runtime writes to the new broken-channel flag or rejected-request tombstone table then fail on upgraded wallets; these schema additions need an append-only migration.

In `packages/rs-platform-wallet/src/wallet/identity/state/managed_identity/contact_requests.rs`:
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/state/managed_identity/contact_requests.rs:109-130: Reject does not persist the incoming-row deletion
  `record_rejected_contact_request` removes the incoming request from memory, but the returned `ContactChangeSet` only populates `cs.rejected`. The storage writer inserts rejected tombstones separately and only deletes live incoming rows when `cs.removed_incoming` is populated, so the stale `state='received'` contact row remains persisted. On the next load or contact restore, that stale row can reappear as a visible incoming request even though the user rejected it.

In `packages/rs-platform-wallet-ffi/src/persistence.rs`:
- [BLOCKING] packages/rs-platform-wallet-ffi/src/persistence.rs:3311-3417: Rejected tombstones are not restored
  The new `restore_dashpay_contacts` bridge restores sent, incoming, and established contact rows, but `IdentityRestoreEntryFFI` has no rejected-tombstone input and this function never repopulates `ManagedIdentity.rejected_contact_requests`. SwiftData likewise treats rejected snapshots as delete-only visible-row operations. After relaunch, Rust has no suppression entry for the immutable rejected contactRequest, while stale incoming rows can still be restored or fetched again, so a rejected request can reappear despite the user's action.

In `packages/rs-platform-wallet/src/wallet/identity/crypto/validation.rs`:
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/crypto/validation.rs:50-79: purpose_mismatch survives hard validation errors
  The type documents `purpose_mismatch` as true only when a key-purpose mismatch is the sole invalidity reason, and the sync code uses that flag to choose retry versus permanent broken-channel handling. However, `add_error` does not clear the flag, `add_purpose_error` sets it unconditionally, and `merge` ORs it. A request with both a hard key error and a purpose error can therefore be retried forever instead of being classified as permanently invalid.

In `packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletPersistenceHandler.swift`:
- [BLOCKING] packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletPersistenceHandler.swift:3031-3047: Wallet deletion omits DashPay payment children
  The SwiftData deletion workaround pre-deletes identity children with non-optional inverse relationships, but it still deletes only DPNS names, DashPay profile, and contact requests. `PersistentDashpayPayment.owner` is also non-optional and is reached through `PersistentIdentity.dashpayPayments`, so a wallet with DashPay payment history can hit the same SwiftData inverse-removal fatal during identity deletion. That aborts the wipe before the wallet row is removed and can leave payment metadata such as memo, counterparty id, amount, and txid on disk.

In `packages/rs-platform-wallet/src/manager/dashpay_sync.rs`:
- [BLOCKING] packages/rs-platform-wallet/src/manager/dashpay_sync.rs:230-232: DashPay sync cleanup can clear a newer cancel token
  The DashPay sync worker still unconditionally sets `background_cancel` to `None` when its loop exits. If `stop()` cancels token A, `start()` installs token B, and the old thread exits afterward, the old cleanup erases B while the new loop is still running. Later `stop()` or shutdown cannot find the live token, so FFI callback context can be freed while an untracked DashPay thread continues calling through Swift-owned callback pointers. The identity and shielded sync managers already use generation guards to avoid this race.

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet-storage/migrations/V001__initial.rs`:
- [BLOCKING] packages/rs-platform-wallet-storage/migrations/V001__initial.rs:178-212: V001 migration edited in place — refinery upgrade from v4.0.0-beta.4 will not pick up new column / table
  Verified at HEAD: `contacts.payment_channel_broken` (line 189) and `CREATE TABLE rejected_contact_requests` (lines 203-212) are added directly into V001, and no V002 migration exists anywhere under `packages/rs-platform-wallet-storage/migrations/` (globbed `V*.rs` returns only V001). V001 (without these additions) shipped in v4.0.0-beta.4, and the storage README enforces append-only migrations because refinery checksums each migration in `refinery_schema_history`. Against an existing beta.4 DB this either aborts on divergent checksum or silently skips V001 as already-applied — neither the new column nor the new table will exist. The first runtime write touching `payment_channel_broken` (`mark_contact_channel_broken`) or `INSERT INTO rejected_contact_requests` (G5 tombstone) then fails at SQLite, disabling the PR's payment-channel-broken safety state and the G5 rejection tombstone on every upgraded wallet. Add a V002 migration: `ALTER TABLE contacts ADD COLUMN payment_channel_broken INTEGER` plus a separate `CREATE TABLE rejected_contact_requests (...)`.

In `packages/rs-platform-wallet-ffi/src/persistence.rs`:
- [BLOCKING] packages/rs-platform-wallet-ffi/src/persistence.rs:3311-3417: Rejected tombstones are written but never restored on rehydration
  `restore_dashpay_contacts` restores sent, incoming, and established rows from the FFI restore spec, but `IdentityRestoreEntryFFI` exposes no rejected-tombstone field — there is no C struct or count/pointer pair for tombstones in the FFI surface at all. The Swift side persists rejected snapshots as write-only deletes on visible rows, and the SQLite reconstruction helper defaults `rejected_contact_requests` to empty. After relaunch, Rust has no suppression entry for the immutable rejected contactRequest, and the sync-loop tombstone check at contact_requests.rs:500 never fires — a rejected request resurfaces on the first sweep. Because the on-platform document is immutable, wiping the tombstone on restart defeats the user's explicit reject and re-exposes them to suppression-bypass by an unwanted sender. Add a per-wallet load reader for `rejected_contact_requests`, surface the rows via a new `rejected_tombstones` field on `IdentityRestoreEntryFFI`, and rehydrate `ManagedIdentity.rejected_contact_requests` from that input.

In `packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletPersistenceHandler.swift`:
- [BLOCKING] packages/swift-sdk/Sources/SwiftDashSDK/PlatformWallet/PlatformWalletPersistenceHandler.swift:3037-3048: Wallet deletion PHASE 1 omits PersistentDashpayPayment children — same fatal pattern as contactRequests
  PHASE 1 iterates `dpnsNames`, `dashpayProfile`, and `contactRequests` but NOT `dashpayPayments`. `PersistentDashpayPayment.owner` is non-optional and `PersistentIdentity.dashpayPayments` is the cascading inverse added in this PR. The surrounding comment explicitly documents that this phase exists because SwiftData fatals during `save()` when it must null out a non-optional inverse on a child processed in the same batch — exactly the shape of the new payments relationship. A wallet with persisted DashPay payment history will hit the SwiftData fatal at PHASE 2 `save()`, aborting before the wallet row is removed. The user believes their data was wiped; plaintext memo + counterparty id + amount + txid rows remain on disk — a confidentiality regression for users handing off or disposing devices.

In `packages/rs-platform-wallet/src/wallet/identity/network/contact_info.rs`:
- [BLOCKING] packages/rs-platform-wallet/src/wallet/identity/network/contact_info.rs:301-308: Disabled encryption keys are still selectable — contactInfo rootEncryptionKeyIndex and contactRequest selector both miss disabled_at
  G7's pre-send validator at `contact_requests.rs:127-138` now gates the contactRequest send path against `validate_contact_request`, which checks `disabled_at`, closing the worst-case 'encrypt DIP-15 compact xpub to a revoked recipient key' confidentiality path. Two residual gaps remain in this PR's scope: (1) `contact_info.rs:301-308` still picks the owner's first ECDSA_SECP256K1 ENCRYPTION key for `rootEncryptionKeyIndex` with no `disabled_at` filter and no equivalent validator gate. The published contactInfo doc references that key id, and if an attacker has the revoked root private material the public id + derivation index lets them derive the same contactInfo AES keys and decrypt the owner's private alias/note/hidden metadata — a real confidentiality exposure on the contactInfo path. (2) `contact_requests.rs:335-351` (`select_recipient_key_index`) still picks the first matching key without `disabled_at`; when a recipient has [disabled DECRYPTION + live ENCRYPTION], the new G7 gate now hard-fails the send instead of falling back to the live ENCRYPTION key — a behavioral regression introduced by this delta. Add `&& k.disabled_at().is_none()` to both selectors so contactInfo is safe and the contactRequest send path picks the live key cleanly.

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet-ffi/src/dashpay.rs`:
- [BLOCKING] packages/rs-platform-wallet-ffi/src/dashpay.rs:175-183: Initialize contact-request array before sync can fail
  `platform_wallet_sync_contact_requests` validates `out_array`, then performs fallible wallet lookup and async Platform sync before writing it. On a stale handle or sync error, the exported C ABI returns with the caller's `ContactRequestHandleArray { handles, count }` untouched, while `platform_wallet_contact_request_handle_array_free` treats those fields as Rust-owned boxed-slice metadata. Initialize the out struct to the empty sentinel before any fallible work so every error path is cleanup-safe.
- [BLOCKING] packages/rs-platform-wallet-ffi/src/dashpay.rs:483-492: Initialize sent-request array before query can fail
  `platform_wallet_fetch_sent_contact_requests` has the same owned-array ABI contract as the sync path, but identity decoding, stale wallet handles, and async fetch errors all return before `*out_array` is assigned. A C/Swift caller that frees the out array on a non-OK result can pass an uninitialized pointer/count pair back into Rust. Publish `ContactRequestHandleArray::empty()` immediately after the pointer check.
- [BLOCKING] packages/rs-platform-wallet-ffi/src/dashpay.rs:175-183: Initialize contact-request array before sync can fail
  `platform_wallet_sync_contact_requests` validates `out_array`, then performs fallible wallet lookup and async Platform sync before writing it. On a stale handle or sync error, the exported C ABI returns with the caller's `ContactRequestHandleArray { handles, count }` untouched, while `platform_wallet_contact_request_handle_array_free` treats those fields as Rust-owned boxed-slice metadata. Initialize the out struct to the empty sentinel before any fallible work so every error path is cleanup-safe.
- [BLOCKING] packages/rs-platform-wallet-ffi/src/dashpay.rs:483-492: Initialize sent-request array before query can fail
  `platform_wallet_fetch_sent_contact_requests` has the same owned-array ABI contract as the sync path, but identity decoding, stale wallet handles, and async fetch errors all return before `*out_array` is assigned. A C/Swift caller that frees the out array on a non-OK result can pass an uninitialized pointer/count pair back into Rust. Publish `ContactRequestHandleArray::empty()` immediately after the pointer check.

In `packages/rs-platform-wallet-ffi/src/dashpay_profile.rs`:
- [BLOCKING] packages/rs-platform-wallet-ffi/src/dashpay_profile.rs:326-329: Initialize profile output before signer profile update can fail
  `platform_wallet_create_or_update_dashpay_profile_with_signer` checks `out_profile`, then can return during identifier decoding, optional C-string decoding, wallet lookup, or async create/update before writing `*out_profile`. `DashPayProfileFFI` owns C-string pointers released by `dashpay_profile_ffi_free`, so the raw ABI should not require callers to pre-zero an owning out struct before a fallible call. Match the sibling profile getters and initialize it to `DashPayProfileFFI::empty()` before fallible work.
- [BLOCKING] packages/rs-platform-wallet-ffi/src/dashpay_profile.rs:326-329: Initialize profile output before signer profile update can fail
  `platform_wallet_create_or_update_dashpay_profile_with_signer` checks `out_profile`, then can return during identifier decoding, optional C-string decoding, wallet lookup, or async create/update before writing `*out_profile`. `DashPayProfileFFI` owns C-string pointers released by `dashpay_profile_ffi_free`, so the raw ABI should not require callers to pre-zero an owning out struct before a fallible call. Match the sibling profile getters and initialize it to `DashPayProfileFFI::empty()` before fallible work.

In `packages/rs-platform-wallet-ffi/src/sign_with_mnemonic_resolver.rs`:
- [BLOCKING] packages/rs-platform-wallet-ffi/src/sign_with_mnemonic_resolver.rs:133-147: Do not change an exported signing symbol's ABI in place
  At the previous reviewed commit, `dash_sdk_sign_with_mnemonic_resolver_and_path` took `network` followed immediately by the output-buffer arguments. This commit inserts `expected_key_data` and `expected_key_data_len` before those outputs while keeping the same `#[no_mangle]` symbol name. Existing generated headers, binary Swift modules, or external C callers compiled against the old prototype will shift every argument after `network`, causing Rust to read the old output pointer as expected key data and write through the wrong out pointers. Keep the old symbol as a compatibility wrapper and add a new versioned symbol for the key-bound form.
- [SUGGESTION] packages/rs-platform-wallet-ffi/src/sign_with_mnemonic_resolver.rs:164-170: Validate expected-key pointer and length together before signing
  The new expected-key binding only runs when `expected_key_data` is non-null and `expected_key_data_len > 0`. That means a malformed FFI call with `expected_key_data = null` and a nonzero length silently skips the binding and signs anyway, even though the API documents null/0 as the intentional way to skip the check. Enforce the pointer/length invariant up front so cross-language call mistakes fail closed.
- [BLOCKING] packages/rs-platform-wallet-ffi/src/sign_with_mnemonic_resolver.rs:133-147: Do not change an exported signing symbol's ABI in place
  At the previous reviewed commit, `dash_sdk_sign_with_mnemonic_resolver_and_path` took `network` followed immediately by the output-buffer arguments. This commit inserts `expected_key_data` and `expected_key_data_len` before those outputs while keeping the same `#[no_mangle]` symbol name. Existing generated headers, binary Swift modules, or external C callers compiled against the old prototype will shift every argument after `network`, causing Rust to read the old output pointer as expected key data and write through the wrong out pointers. Keep the old symbol as a compatibility wrapper and add a new versioned symbol for the key-bound form.
- [SUGGESTION] packages/rs-platform-wallet-ffi/src/sign_with_mnemonic_resolver.rs:164-170: Validate expected-key pointer and length together before signing
  The new expected-key binding only runs when `expected_key_data` is non-null and `expected_key_data_len > 0`. That means a malformed FFI call with `expected_key_data = null` and a nonzero length silently skips the binding and signs anyway, even though the API documents null/0 as the intentional way to skip the check. Enforce the pointer/length invariant up front so cross-language call mistakes fail closed.

In `packages/rs-platform-wallet-ffi/src/established_contact.rs`:
- [SUGGESTION] packages/rs-platform-wallet-ffi/src/established_contact.rs:160-167: Null the note out-parameter before fallible lookup
  `established_contact_get_note` writes `*out_note` only after handle lookup, note lookup, and `CString::new` all succeed. Stale handles, missing notes, and interior-NUL failures leave the caller's pointer slot unchanged even though the success path returns an owned C string. Set the out pointer to null before the lookup so error paths are deterministic and cleanup-safe.
- [SUGGESTION] packages/rs-platform-wallet-ffi/src/established_contact.rs:160-167: Null the note out-parameter before fallible lookup
  `established_contact_get_note` writes `*out_note` only after handle lookup, note lookup, and `CString::new` all succeed. Stale handles, missing notes, and interior-NUL failures leave the caller's pointer slot unchanged even though the success path returns an owned C string. Set the out pointer to null before the lookup so error paths are deterministic and cleanup-safe.

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet-storage/src/sqlite/schema/identity_keys.rs`:
- [BLOCKING] packages/rs-platform-wallet-storage/src/sqlite/schema/identity_keys.rs:70-82: platform-wallet-storage no longer compiles — stale IdentityKeyEntry.private_key field
  The scalar-elimination commit (930c100c) removed `private_key` from `IdentityKeyEntry`, but `IdentityKeyWire::into_entry` still constructs the struct with `private_key: None` at line 80. `cargo check -p platform-wallet-storage --tests` fails with `E0560: struct IdentityKeyEntry has no field named private_key`. Because the surrounding block is `#[cfg(any(test, feature = "__test-helpers"))]`, the plain `cargo check -p platform-wallet-storage` still passes — this is how the refactor slipped past local verification. The same file also has `private_key: Some(zeroize::Zeroizing::new([0xC7; 32]))` at line 222 and `restored.private_key.is_none()` at line 229 inside the `wire_round_trip_drops_signing_scalar` test that need to be removed together.

In `packages/rs-platform-wallet-storage/tests/sqlite_persist_roundtrip.rs`:
- [BLOCKING] packages/rs-platform-wallet-storage/tests/sqlite_persist_roundtrip.rs:225-236: sqlite_persist_roundtrip test constructs IdentityKeyEntry with removed field
  This integration test still initializes `IdentityKeyEntry` with `private_key: None` after the field was removed. Blocks `cargo test -p platform-wallet-storage`.

In `packages/rs-platform-wallet-storage/tests/sqlite_structural_hardening.rs`:
- [BLOCKING] packages/rs-platform-wallet-storage/tests/sqlite_structural_hardening.rs:310-318: sqlite_structural_hardening test constructs IdentityKeyEntry with removed field
  Same compile-breaking pattern as sqlite_persist_roundtrip.rs — `private_key: None` no longer resolves against the current `IdentityKeyEntry`. Must be dropped for `cargo test -p platform-wallet-storage` to build.

In `packages/rs-platform-wallet-ffi/src/dashpay.rs`:
- [BLOCKING] packages/rs-platform-wallet-ffi/src/dashpay.rs:175-183: Initialize contact-request array before sync can fail
  STILL VALID prior finding, unchanged at head. `platform_wallet_sync_contact_requests` validates `out_array`, then performs fallible wallet lookup and async Platform sync before writing it. On a stale handle or Platform/DAPI error, the exported C ABI returns non-OK with the caller's `ContactRequestHandleArray { handles, count }` untouched. `platform_wallet_contact_request_handle_array_free` interprets those fields as Rust-owned boxed-slice metadata and calls `Box::from_raw` — a C/Swift caller that runs unconditional cleanup on a non-OK result frees uninitialized memory. Because the error path can be triggered by remote peer behavior, this is an FFI-boundary memory-corruption primitive. Publish the empty sentinel immediately after `check_ptr!`.
- [BLOCKING] packages/rs-platform-wallet-ffi/src/dashpay.rs:483-492: Initialize sent-request array before query can fail
  STILL VALID prior finding, unchanged at head. `platform_wallet_fetch_sent_contact_requests` has the same owned-array ABI contract as the sync path: `read_identifier`, stale wallet handles, and async fetch errors all return before `*out_array` is written. Because the fetch depends on remote Platform responses, an attacker positioned to answer that endpoint can force the error path deterministically. Publish `ContactRequestHandleArray::empty()` immediately after the pointer check, before `read_identifier`.
- [BLOCKING] packages/rs-platform-wallet-ffi/src/dashpay.rs:175-183: Initialize contact-request array before sync can fail
  STILL VALID prior finding, unchanged at head. `platform_wallet_sync_contact_requests` validates `out_array`, then performs fallible wallet lookup and async Platform sync before writing it. On a stale handle or Platform/DAPI error, the exported C ABI returns non-OK with the caller's `ContactRequestHandleArray { handles, count }` untouched. `platform_wallet_contact_request_handle_array_free` interprets those fields as Rust-owned boxed-slice metadata and calls `Box::from_raw` — a C/Swift caller that runs unconditional cleanup on a non-OK result frees uninitialized memory. Because the error path can be triggered by remote peer behavior, this is an FFI-boundary memory-corruption primitive. Publish the empty sentinel immediately after `check_ptr!`.
- [BLOCKING] packages/rs-platform-wallet-ffi/src/dashpay.rs:483-492: Initialize sent-request array before query can fail
  STILL VALID prior finding, unchanged at head. `platform_wallet_fetch_sent_contact_requests` has the same owned-array ABI contract as the sync path: `read_identifier`, stale wallet handles, and async fetch errors all return before `*out_array` is written. Because the fetch depends on remote Platform responses, an attacker positioned to answer that endpoint can force the error path deterministically. Publish `ContactRequestHandleArray::empty()` immediately after the pointer check, before `read_identifier`.

In `packages/rs-platform-wallet-ffi/src/dashpay_profile.rs`:
- [BLOCKING] packages/rs-platform-wallet-ffi/src/dashpay_profile.rs:326-329: Initialize profile output before signer profile update can fail
  STILL VALID prior finding, unchanged at head. `platform_wallet_create_or_update_dashpay_profile_with_signer` checks `out_profile` and `signer_handle`, then can return during `read_identifier`, three `decode_opt_c_str` calls, wallet lookup, or the async create/update before writing `*out_profile`. `DashPayProfileFFI` owns three C-string pointers (display_name / public_message / avatar_url) released by `dashpay_profile_ffi_free` via `platform_wallet_string_free`. A caller that runs cleanup after non-OK frees uninitialized pointer fields. Zero-initialize before any fallible step.
- [BLOCKING] packages/rs-platform-wallet-ffi/src/dashpay_profile.rs:326-329: Initialize profile output before signer profile update can fail
  STILL VALID prior finding, unchanged at head. `platform_wallet_create_or_update_dashpay_profile_with_signer` checks `out_profile` and `signer_handle`, then can return during `read_identifier`, three `decode_opt_c_str` calls, wallet lookup, or the async create/update before writing `*out_profile`. `DashPayProfileFFI` owns three C-string pointers (display_name / public_message / avatar_url) released by `dashpay_profile_ffi_free` via `platform_wallet_string_free`. A caller that runs cleanup after non-OK frees uninitialized pointer fields. Zero-initialize before any fallible step.

In `packages/rs-platform-wallet-ffi/src/sign_with_mnemonic_resolver.rs`:
- [BLOCKING] packages/rs-platform-wallet-ffi/src/sign_with_mnemonic_resolver.rs:133-147: Do not change an exported signing symbol's ABI in place
  STILL VALID prior finding, unchanged at head. `dash_sdk_sign_with_mnemonic_resolver_and_path` gained two arguments (`expected_key_data`, `expected_key_data_len`) inserted between `network` and the output-buffer arguments while keeping the same `#[no_mangle]` symbol name. Any generated header, pre-compiled Swift module, or external C caller compiled against the previous prototype will shift every argument after `network`: Rust reads the old `out_signature` pointer as `expected_key_data`, uses the old `out_signature_capacity` as `expected_key_data_len`, and writes signature bytes through the wrong pointers — undefined behavior on every call, and the pubkey-binding guard runs against caller-buffer contents. Keep the old symbol as a compatibility wrapper (bind-null internally) and export the new key-bound form under a versioned symbol name, or delete the old symbol entirely if this branch is the only consumer.
- [SUGGESTION] packages/rs-platform-wallet-ffi/src/sign_with_mnemonic_resolver.rs:164-170: Validate expected-key pointer and length together before signing
  STILL VALID prior finding, unchanged at head. The expected-key binding at line 257 only runs when `expected_key_data` is non-null AND `expected_key_data_len > 0`. Two malformed cross-language marshaling shapes silently skip the binding and sign anyway: (a) `expected_key_data = null` with a nonzero length, and (b) a non-null pointer with `expected_key_data_len == 0`. The API docs treat null/0 as the intentional way to opt out, but paired-inconsistent shapes now bypass the very guardrail this PR added. Fail closed by enforcing the pointer/length invariant up front in the argument validation block.
- [BLOCKING] packages/rs-platform-wallet-ffi/src/sign_with_mnemonic_resolver.rs:133-147: Do not change an exported signing symbol's ABI in place
  STILL VALID prior finding, unchanged at head. `dash_sdk_sign_with_mnemonic_resolver_and_path` gained two arguments (`expected_key_data`, `expected_key_data_len`) inserted between `network` and the output-buffer arguments while keeping the same `#[no_mangle]` symbol name. Any generated header, pre-compiled Swift module, or external C caller compiled against the previous prototype will shift every argument after `network`: Rust reads the old `out_signature` pointer as `expected_key_data`, uses the old `out_signature_capacity` as `expected_key_data_len`, and writes signature bytes through the wrong pointers — undefined behavior on every call, and the pubkey-binding guard runs against caller-buffer contents. Keep the old symbol as a compatibility wrapper (bind-null internally) and export the new key-bound form under a versioned symbol name, or delete the old symbol entirely if this branch is the only consumer.
- [SUGGESTION] packages/rs-platform-wallet-ffi/src/sign_with_mnemonic_resolver.rs:164-170: Validate expected-key pointer and length together before signing
  STILL VALID prior finding, unchanged at head. The expected-key binding at line 257 only runs when `expected_key_data` is non-null AND `expected_key_data_len > 0`. Two malformed cross-language marshaling shapes silently skip the binding and sign anyway: (a) `expected_key_data = null` with a nonzero length, and (b) a non-null pointer with `expected_key_data_len == 0`. The API docs treat null/0 as the intentional way to opt out, but paired-inconsistent shapes now bypass the very guardrail this PR added. Fail closed by enforcing the pointer/length invariant up front in the argument validation block.

In `packages/rs-platform-wallet-ffi/src/identity_persistence.rs`:
- [BLOCKING] packages/rs-platform-wallet-ffi/src/identity_persistence.rs:236-347: IdentityKeyEntryFFI struct shrunk in place — same ABI-break class as the signing symbol
  New in this delta. The scalar-elimination refactor removes the trailing `private_key_is_some: bool` and `private_key: [u8; 32]` fields from the exported `#[repr(C)]` `IdentityKeyEntryFFI` and shrinks the compile-time guard from 224 to 184 bytes, while keeping the same `on_persist_identity_keys_fn` callback contract. Any caller compiled against the previous header will still stride the `upserts_ptr` array as 224-byte rows and read the removed trailing fields off the end (or into the next row), causing memory corruption or misparsed callback data. This is the same class of concern as the `dash_sdk_sign_with_mnemonic_resolver_and_path` in-place ABI change — the in-repo Swift wrapper was updated in lockstep but any external cbindgen-consumer compiled against the previous layout is broken silently. Preserve the removed fields as deprecated zero-filled padding until a versioned callback slot is added, or bump/rename the callback signature so old and new layouts cannot be confused.
- [BLOCKING] packages/rs-platform-wallet-ffi/src/identity_persistence.rs:236-347: IdentityKeyEntryFFI struct shrunk in place — same ABI-break class as the signing symbol
  New in this delta. The scalar-elimination refactor removes the trailing `private_key_is_some: bool` and `private_key: [u8; 32]` fields from the exported `#[repr(C)]` `IdentityKeyEntryFFI` and shrinks the compile-time guard from 224 to 184 bytes, while keeping the same `on_persist_identity_keys_fn` callback contract. Any caller compiled against the previous header will still stride the `upserts_ptr` array as 224-byte rows and read the removed trailing fields off the end (or into the next row), causing memory corruption or misparsed callback data. This is the same class of concern as the `dash_sdk_sign_with_mnemonic_resolver_and_path` in-place ABI change — the in-repo Swift wrapper was updated in lockstep but any external cbindgen-consumer compiled against the previous layout is broken silently. Preserve the removed fields as deprecated zero-filled padding until a versioned callback slot is added, or bump/rename the callback signature so old and new layouts cannot be confused.

In `packages/rs-platform-wallet-ffi/src/established_contact.rs`:
- [SUGGESTION] packages/rs-platform-wallet-ffi/src/established_contact.rs:160-167: Null the note out-parameter before fallible lookup
  STILL VALID prior finding, unchanged at head. `established_contact_get_note` writes `*out_note` only after handle lookup, note lookup, and `CString::new` all succeed. Stale handles, missing notes, and interior-NUL failures leave the caller's pointer slot unchanged even though the success path returns an owned C string that must be freed with `platform_wallet_string_free`. A caller that unconditionally frees `*out_note` on the shape of the success path hits use-after-free of whatever the slot held pre-call. Null the pointer before the lookup.
- [SUGGESTION] packages/rs-platform-wallet-ffi/src/established_contact.rs:160-167: Null the note out-parameter before fallible lookup
  STILL VALID prior finding, unchanged at head. `established_contact_get_note` writes `*out_note` only after handle lookup, note lookup, and `CString::new` all succeed. Stale handles, missing notes, and interior-NUL failures leave the caller's pointer slot unchanged even though the success path returns an owned C string that must be freed with `platform_wallet_string_free`. A caller that unconditionally frees `*out_note` on the shape of the success path hits use-after-free of whatever the slot held pre-call. Null the pointer before the lookup.

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet-storage/src/sqlite/schema/identity_keys.rs`:
- [BLOCKING] packages/rs-platform-wallet-storage/src/sqlite/schema/identity_keys.rs:70-82: platform-wallet-storage test build broken — stale IdentityKeyEntry.private_key field
  STILL_VALID at 95d6714f (unanimous across all six reviewers). The scalar-elimination refactor (930c100c) removed `private_key` from `IdentityKeyEntry` (verified: `packages/rs-platform-wallet/src/changeset/changeset.rs` no longer defines that field), but `IdentityKeyWire::into_entry` at line 80 still constructs the struct with `private_key: None` under `#[cfg(any(test, feature = "__test-helpers"))]`. Plain `cargo check -p platform-wallet-storage` passes because the cfg-gated block is skipped, but `cargo check -p platform-wallet-storage --tests` fails with `E0560: struct IdentityKeyEntry has no field named private_key` at this line — which is how the regression slipped past. The in-file test `wire_round_trip_drops_signing_scalar` at lines 222 and 229 also references the removed field and must be updated in the same edit. Because this is the durable persistence crate the FFI + Swift SDK ride on, the compile break silently disables the storage-side regression tests that assert 'no signing scalar reaches disk' — the exact invariant this PR advertises.

In `packages/rs-platform-wallet-storage/tests/sqlite_persist_roundtrip.rs`:
- [BLOCKING] packages/rs-platform-wallet-storage/tests/sqlite_persist_roundtrip.rs:225-236: sqlite_persist_roundtrip constructs IdentityKeyEntry with removed private_key field
  STILL_VALID at 95d6714f. Line 235 still initializes `IdentityKeyEntry { …, private_key: None }` against a struct that no longer has that field. Blocks `cargo test -p platform-wallet-storage` — this is the primary regression harness for the on-disk shape of persisted identity-key rows. Drop `private_key: None` in the same edit as the identity_keys.rs fix.

In `packages/rs-platform-wallet-storage/tests/sqlite_structural_hardening.rs`:
- [BLOCKING] packages/rs-platform-wallet-storage/tests/sqlite_structural_hardening.rs:310-318: sqlite_structural_hardening constructs IdentityKeyEntry with removed private_key field
  STILL_VALID at 95d6714f. Line 317 still initializes `IdentityKeyEntry { …, private_key: None }`. Same E0560 compile break as the other two sites; blocks the structural-hardening test target that pins the row-boundary and blob-vs-column invariants for the SQLite persistence layer.

In `packages/rs-platform-wallet-ffi/src/dashpay.rs`:
- [BLOCKING] packages/rs-platform-wallet-ffi/src/dashpay.rs:170-185: platform_wallet_sync_contact_requests: initialize owned out_array before fallible sync
  STILL_VALID at 95d6714f (verified verbatim: line 175 does `check_ptr!(out_array)`, then a fallible `PLATFORM_WALLET_STORAGE.with_item` lookup + async `sync_contact_requests().await`, then writes `*out_array` only on the success path at line 183). On a stale wallet handle or Platform/DAPI error, the function returns non-OK and the caller's `ContactRequestHandleArray { handles, count }` is left with whatever bytes it held before the call. `platform_wallet_contact_request_handle_array_free` treats those fields as Rust-owned boxed-slice metadata and calls `Box::from_raw` on `handles` sized by `count` — so a Swift/C caller that runs unconditional cleanup on non-OK (the standard `defer`-style pattern) frees uninitialized pointer bits. The error path is remotely reachable (any DAPI failure), giving an externally-driven FFI memory-corruption primitive. Publish `ContactRequestHandleArray::empty()` immediately after `check_ptr!`, before any fallible step.
- [BLOCKING] packages/rs-platform-wallet-ffi/src/dashpay.rs:478-494: platform_wallet_fetch_sent_contact_requests: initialize owned out_array before fallible fetch
  STILL_VALID at 95d6714f. Same owned-array ABI hazard as `platform_wallet_sync_contact_requests`: between `check_ptr!(out_array)` and `*out_array = …`, three fallible steps (identifier decoding, stale wallet handle lookup, async `sent_contact_requests(&id).await`) can return non-OK. Because the fetch depends on a remote Platform response, an attacker positioned to answer or disrupt the endpoint forces the error path deterministically; a caller's cleanup-on-error path then feeds `Box::from_raw` an uninitialized pointer/count pair. Publish `ContactRequestHandleArray::empty()` right after the pointer check.

In `packages/rs-platform-wallet-ffi/src/dashpay_profile.rs`:
- [BLOCKING] packages/rs-platform-wallet-ffi/src/dashpay_profile.rs:314-333: platform_wallet_create_or_update_dashpay_profile_with_signer: initialize owned out_profile before fallible steps
  STILL_VALID at 95d6714f. `check_ptr!(out_profile)` and `check_ptr!(signer_handle)` at lines 326-327 are followed by `read_identifier`, three `decode_opt_c_str` calls, a wallet-storage handle lookup, and the async signer-driven create/update — any of which can return non-OK before `*out_profile` is written. `DashPayProfileFFI` owns three heap C-string pointers (display_name / public_message / avatar_url) released by `dashpay_profile_ffi_free` via `platform_wallet_string_free` (i.e. `CString::from_raw` on each). A caller running unconditional cleanup after non-OK feeds `CString::from_raw` arbitrary bit patterns from the caller's stack — an unbounded-free primitive at the FFI trust boundary. Zero-initialize before any fallible step (sibling profile getters already do this).

In `packages/rs-platform-wallet-ffi/src/sign_with_mnemonic_resolver.rs`:
- [BLOCKING] packages/rs-platform-wallet-ffi/src/sign_with_mnemonic_resolver.rs:133-147: Silent in-place ABI change on exported dash_sdk_sign_with_mnemonic_resolver_and_path
  STILL_VALID at 95d6714f. The `#[no_mangle] pub unsafe extern "C"` signing symbol grew two arguments (`expected_key_data: *const u8`, `expected_key_data_len: usize`) inserted between `network` and the output-buffer arguments while keeping the same exported symbol name. Any caller compiled against the previous prototype (generated cbindgen header, pre-compiled Swift binary framework, external C consumer) shifts every argument after `network`: Rust reads the old `out_signature` pointer as `expected_key_data`, the old `out_signature_capacity` as `expected_key_data_len`, then writes signature bytes through the wrong pointers — undefined behavior on every call, and the new pubkey-binding guard runs against caller-buffer contents instead of the intended key material. Version the symbol (e.g. `_v2` / `_with_expected_key`) and keep the old symbol as a compatibility wrapper that binds null internally, or delete the old name so mismatched links fail loudly.
- [SUGGESTION] packages/rs-platform-wallet-ffi/src/sign_with_mnemonic_resolver.rs:164-172: Enforce paired expected_key_data pointer/length invariant up front
  STILL_VALID at 95d6714f. The pubkey-binding downstream (line 257) only fires when `expected_key_data` is non-null AND `expected_key_data_len > 0`. Two malformed cross-language marshaling shapes silently skip the binding and produce a signature anyway: (a) `expected_key_data = null` with `expected_key_data_len > 0`, and (b) non-null pointer with `expected_key_data_len == 0`. The API docs treat null/0 as the intentional opt-out, so paired-inconsistent shapes are contract violations that bypass the very impersonation-resistance guard this PR added. Fail closed by enforcing the pointer/length invariant in the argument-validation block before any resolve/derivation work.

In `packages/rs-platform-wallet-ffi/src/identity_persistence.rs`:
- [BLOCKING] packages/rs-platform-wallet-ffi/src/identity_persistence.rs:236-348: IdentityKeyEntryFFI shrunk in place (224→184 bytes) under unchanged callback contract
  STILL_VALID at 95d6714f (compile-time guard at line 347 now pins `size_of::<IdentityKeyEntryFFI>() == 184`, down from 224). The scalar-elimination refactor removed the trailing `private_key_is_some: bool` and `private_key: [u8; 32]` fields from the exported `#[repr(C)] IdentityKeyEntryFFI` while keeping the same `on_persist_identity_keys_fn` callback contract, symbol name, and callback slot. Any Swift/C consumer compiled against the previous 224-byte header will still stride the `upserts_ptr` array as 224-byte rows: subsequent rows are misparsed (reading `contract_bounds_kind` from the middle of the next row's `identity_id`), and per-row callbacks read the removed `private_key_is_some` byte from adjacent memory — memory corruption or callback misparse driven by every ordinary identity-key persist. Version the callback (e.g. `set_persist_identity_keys_callback_v2` / `persistIdentityKeysV2`) or preserve the removed fields as deprecated zero-filled padding for one release cycle so mixed-version linkage fails at load rather than silently corrupts.

In `packages/rs-platform-wallet-ffi/src/established_contact.rs`:
- [SUGGESTION] packages/rs-platform-wallet-ffi/src/established_contact.rs:156-169: established_contact_get_note: null out_note before fallible lookup
  STILL_VALID at 95d6714f. `established_contact_get_note` writes `*out_note` only after handle lookup, note-presence check, and `CString::new` all succeed. Stale handles, missing notes (`contact.note == None`), and interior-NUL failures leave the caller's pointer slot unchanged, even though the success path returns an owned C-string that must be released with `platform_wallet_string_free` (which is `CString::from_raw`). A Swift caller with the common `defer { platform_wallet_string_free(ptr) }` pattern after unwrapping OK hits use-after-free / arbitrary-free of whatever the slot held pre-call. Null the pointer immediately after `check_ptr!`.

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet-ffi/src/dashpay.rs`:
- [BLOCKING] packages/rs-platform-wallet-ffi/src/dashpay.rs:171-185: [carried-forward prior-4] platform_wallet_sync_contact_requests leaves *out_array uninitialized on failure
  Verified at head 78fa9166 (verbatim unchanged since 738f1eed). `check_ptr!(out_array)` at line 175 only null-checks the pointer; `*out_array` is written exactly once at line 183, after two fallible steps (`with_item` wallet-handle lookup at 177-180, async `sync_contact_requests().await`) that can early-return via `unwrap_option_or_return!` / `unwrap_result_or_return!` at 181-182. On any Platform-side or handle failure the caller's `ContactRequestHandleArray { handles, count }` retains whatever pre-call bytes it held. `platform_wallet_contact_request_handle_array_free` (this file, 143-158) treats those fields as a Rust-owned boxed slice and drives `Box::from_raw`; its `array.handles.is_null()` guard only catches null pointers, not garbage-non-null bit patterns. A Swift/C caller using the common `defer { …_free(&array) }` cleanup pattern after a non-OK result feeds `Box::from_raw` uninitialized bits — an externally reachable heap-corruption primitive over any Platform sync failure. Sibling FFI (`dpns.rs`, `dashpay_payment.rs`) already publishes an empty sentinel before fallible work.

  Suggested fix:
      check_ptr!(out_array);
      unsafe { *out_array = ContactRequestHandleArray::empty() };
  
      let option = PLATFORM_WALLET_STORAGE.with_item(wallet_handle, |wallet| {
          let identity = wallet.identity().clone();
          block_on_worker(async move { identity.sync_contact_requests().await })
      });
      let result = unwrap_option_or_return!(option);
      let list = unwrap_result_or_return!(result);
      unsafe { *out_array = ContactRequestHandleArray::from_requests(list) };
      PlatformWalletFFIResult::ok()
  }
- [BLOCKING] packages/rs-platform-wallet-ffi/src/dashpay.rs:478-494: [carried-forward prior-5] platform_wallet_fetch_sent_contact_requests leaves *out_array uninitialized on failure
  Verified at head 78fa9166 (unchanged since 738f1eed). Same owned-array hazard as prior-4: between `check_ptr!(out_array)` at line 483 and `*out_array = …` at line 492, three fallible steps run (identifier decoding at 484, wallet-handle lookup, async `sent_contact_requests(&id).await`), each of which can early-return without writing the output. Because the query depends on a remote Platform response, an adversary that can disrupt the endpoint or feed malformed identifier bytes can deterministically force the error path, after which a caller's cleanup path feeds `Box::from_raw` uninitialized bits. Same fix as prior-4: publish `ContactRequestHandleArray::empty()` right after the pointer check.

  Suggested fix:
      check_ptr!(out_array);
      unsafe { *out_array = ContactRequestHandleArray::empty() };
      let id = unwrap_result_or_return!(unsafe { read_identifier(identity_id) });
  
      let option = PLATFORM_WALLET_STORAGE.with_item(wallet_handle, |wallet| {
          let identity = wallet.identity().clone();
          block_on_worker(async move { identity.sent_contact_requests(&id).await })
      });
      let result = unwrap_option_or_return!(option);
      let list = unwrap_result_or_return!(result);
      unsafe { *out_array = ContactRequestHandleArray::from_requests(list) };
      PlatformWalletFFIResult::ok()
  }

In `packages/rs-platform-wallet-ffi/src/dashpay_profile.rs`:
- [BLOCKING] packages/rs-platform-wallet-ffi/src/dashpay_profile.rs:314-368: [carried-forward prior-6] platform_wallet_create_or_update_dashpay_profile_with_signer leaves *out_profile uninitialized on failure
  Verified at head 78fa9166 (unchanged since 738f1eed). `check_ptr!(out_profile)` / `check_ptr!(signer_handle)` at 326-327 are followed by `read_identifier` (329), three `decode_opt_c_str` calls (331-333), a wallet-storage handle lookup (343), and the async signer-driven create/update — any of which can return non-OK before `*out_profile = DashPayProfileFFI::from_profile(&profile)` at 367. `DashPayProfileFFI` owns three heap C-string pointers (display_name / public_message / avatar_url) released by `dashpay_profile_ffi_free` via `CString::from_raw`. A caller running unconditional cleanup after non-OK feeds `CString::from_raw` arbitrary bit patterns from the caller's stack — an unbounded-free primitive at the FFI trust boundary. Sibling profile getters in this same file already zero-initialize before fallible work; write `*out_profile = DashPayProfileFFI::empty()` immediately after the pointer checks so every subsequent early-return leaves the slot in a safely-freeable state.

  Suggested fix:
      check_ptr!(out_profile);
      check_ptr!(signer_handle);
      unsafe { *out_profile = DashPayProfileFFI::empty() };

In `packages/rs-platform-wallet-ffi/src/sign_with_mnemonic_resolver.rs`:
- [BLOCKING] packages/rs-platform-wallet-ffi/src/sign_with_mnemonic_resolver.rs:119-135: [carried-forward prior-7] Silent in-place ABI change on exported dash_sdk_sign_with_mnemonic_resolver_and_path
  Verified at head 78fa9166 (unchanged since 738f1eed). The `#[no_mangle] pub unsafe extern "C"` signing symbol grew two arguments (`expected_key_data: *const u8` at position 8, `expected_key_data_len: usize` at position 9) inserted between `network` and the output pointers while retaining its exported name. In-tree Swift callers (`KeychainSigner.swift`) were updated in the same commit, but C symbols carry no ABI version: any consumer linking against a pre-compiled xcframework or an external C consumer built against the previous prototype will silently reinterpret every argument after `network` — Rust reads the old `out_signature` pointer as `expected_key_data`, and so on — an arbitrary read/write primitive under the caller's control at a signing entry point. CLAUDE.md's own iOS troubleshooting notes explicitly call out stale-binary risk after merges. Version the symbol (e.g. `_v2` / `_with_expected_key`) or keep the old name as a compatibility shim that binds a null/0 expected key internally, so a stale caller fails to link rather than mis-marshaling into a signing function.

In `packages/rs-platform-wallet-ffi/src/identity_persistence.rs`:
- [BLOCKING] packages/rs-platform-wallet-ffi/src/identity_persistence.rs:236-348: [carried-forward prior-8] IdentityKeyEntryFFI shrunk in place (224→184 bytes) under unchanged callback contract
  Verified at head 78fa9166. The compile-time guard at line 347 (`const _: [u8; 184] = [0u8; std::mem::size_of::<IdentityKeyEntryFFI>()];`) pins the new 184-byte layout, down from the pre-refactor 224. The scalar-elimination refactor removed the trailing `private_key_is_some: bool` and `private_key: [u8; 32]` fields from the exported `#[repr(C)] IdentityKeyEntryFFI` while keeping the `on_persist_identity_keys_fn` callback contract, symbol name, and slot unchanged. In-tree Swift regenerates its header via cbindgen at build time, so it is fine — the risk is external: any consumer with a pre-generated 224-byte header or a pre-built xcframework strides the `upserts_ptr` array in 224-byte increments over a Rust-side 184-byte stride. Every row after the first is misparsed (reading `contract_bounds_kind` from the middle of the next row's `identity_id`), and the last row reads past the allocation — memory corruption driven by every ordinary identity-key persist under mixed-version linkage. Version the callback (`set_persist_identity_keys_callback_v2` / `persistIdentityKeysV2`) so mixed-version linkage fails at load rather than silently corrupts.

In `packages/rs-platform-wallet-ffi/src/sign_with_mnemonic_resolver.rs`:
- [SUGGESTION] packages/rs-platform-wallet-ffi/src/sign_with_mnemonic_resolver.rs:152-160: [carried-forward prior-10] Enforce paired expected_key_data pointer/length invariant up front — fails open
  Verified at head 78fa9166 (argument validation at 152-160 unchanged; binding guard at line 245 verified). The pubkey-binding guard `if !expected_key_data.is_null() && expected_key_data_len > 0` only fires when both fields are consistently set. Two malformed marshaling shapes silently skip the impersonation-resistance binding and still produce a signature: (a) `expected_key_data = null` with `expected_key_data_len > 0`, and (b) non-null pointer with `expected_key_data_len == 0`. The docstring treats `(null, 0)` as the intentional opt-out, so paired-inconsistent shapes are contract violations that bypass the very guard this PR added. Since this parameter exists specifically to prevent signing under a wrong/stale derived key, a mis-marshaled caller argument pair should fail closed with `SIGN_WITH_RESOLVER_ERR_NULL_POINTER`, not silently disable the security check.

  Suggested fix:
      if mnemonic_resolver_handle.is_null()
          || wallet_id_bytes.is_null()
          || derivation_path_cstr.is_null()
          || out_signature.is_null()
          || out_signature_len.is_null()
          || (data.is_null() && data_len > 0)
          || (expected_key_data.is_null() && expected_key_data_len > 0)
          || (!expected_key_data.is_null() && expected_key_data_len == 0)
      {
          return fail(SIGN_WITH_RESOLVER_ERR_NULL_POINTER);
      }

In `packages/rs-platform-wallet-ffi/src/established_contact.rs`:
- [SUGGESTION] packages/rs-platform-wallet-ffi/src/established_contact.rs:156-169: [carried-forward prior-9] established_contact_get_note: null *out_note before fallible lookup
  Verified at head 78fa9166 (unchanged since 738f1eed). `established_contact_get_note` writes `*out_note = c_str.into_raw()` at line 167 only after handle lookup (162), note-presence (164-165), and `CString::new` (166) all succeed. Stale handles, missing notes, and interior-NUL failures leave the caller's `*mut c_char` slot unchanged, even though the success path returns an owned C-string that must be released with `platform_wallet_string_free` (`CString::from_raw`). A Swift caller using the common `defer { platform_wallet_string_free(ptr) }` pattern after unwrapping OK hits use-after-free / arbitrary-free of whatever the slot held pre-call. The in-repo Swift wrapper does zero-init before the call so this is currently safe in practice, but the FFI function should honor the defensive 'always safe to free' contract used elsewhere in this crate by nulling the pointer immediately after `check_ptr!`.

  Suggested fix:
      check_ptr!(out_note);
      unsafe { *out_note = std::ptr::null_mut() };
  
      let option =
          ESTABLISHED_CONTACT_STORAGE.with_item(contact_handle, |contact| contact.note.clone());
      let option = unwrap_option_or_return!(option);
      let note = unwrap_option_or_return!(option);
      let c_str = unwrap_result_or_return!(std::ffi::CString::new(note));
      unsafe { *out_note = c_str.into_raw() };
      PlatformWalletFFIResult::ok()
  }

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `packages/rs-platform-wallet-ffi/src/dashpay.rs`:
- [BLOCKING] packages/rs-platform-wallet-ffi/src/dashpay.rs:171-185: platform_wallet_sync_contact_requests leaves *out_array uninitialized on every failure path
  Reconciled STILL_VALID at bb02c416 (unchanged since 78fa9166). `check_ptr!(out_array)` at line 175 only null-checks the pointer; `*out_array` is written exactly once at line 183, after two fallible steps — `PLATFORM_WALLET_STORAGE.with_item` handle lookup and the async `sync_contact_requests().await` — either of which can early-return via `unwrap_option_or_return!` / `unwrap_result_or_return!` without touching the caller's slot. `ContactRequestHandleArray` is heap-owned; the paired `platform_wallet_contact_request_handle_array_free` (lines 143-158) reconstructs a boxed slice via `Box::from_raw` when `handles` is non-null and `count != 0`, guarded only against null. A caller who follows the common cleanup-on-error pattern (deferred `..._free`) after a non-OK result feeds `Box::from_raw` whatever bytes the caller's `ContactRequestHandleArray` slot happened to hold — an FFI-boundary heap-corruption primitive whenever a Platform sync fails. In-tree Swift call sites happen to zero-initialize and guard the free, but the C ABI contract should not require every consumer to know that convention. Publish `ContactRequestHandleArray::empty()` right after the pointer check, matching the pattern already used by sibling FFI (`dpns.rs`, `dashpay_payment.rs`).
- [BLOCKING] packages/rs-platform-wallet-ffi/src/dashpay.rs:478-494: platform_wallet_fetch_sent_contact_requests leaves *out_array uninitialized on failure
  Reconciled STILL_VALID at bb02c416 (unchanged). Same owned-array hazard as the sync-side finding: between `check_ptr!(out_array)` at line 483 and the sole write at line 492, three fallible steps run — identifier decoding (`read_identifier`, line 484), wallet-handle lookup, and the async `sent_contact_requests(&id).await` — any of which can early-return without initializing the output. Because the query depends on a remote Platform response, an unreachable endpoint or malformed identifier input deterministically hits the error path, after which cleanup-on-error at the caller feeds `Box::from_raw` uninitialized/stale pointer+count bits at `platform_wallet_contact_request_handle_array_free`. Same fix: publish `ContactRequestHandleArray::empty()` immediately after the pointer check.

In `packages/rs-platform-wallet-ffi/src/dashpay_profile.rs`:
- [BLOCKING] packages/rs-platform-wallet-ffi/src/dashpay_profile.rs:314-369: platform_wallet_create_or_update_dashpay_profile_with_signer leaves *out_profile uninitialized on failure
  Reconciled STILL_VALID at bb02c416 (unchanged). `check_ptr!(out_profile)` / `check_ptr!(signer_handle)` at 326-327 are followed by `read_identifier` (329), three `decode_opt_c_str` calls (331-333), a `PLATFORM_WALLET_STORAGE.with_item` handle lookup (343), and the async signer-driven create/update — any of which can return non-OK before `*out_profile = DashPayProfileFFI::from_profile(&profile)` at 367. `DashPayProfileFFI` owns three heap C-string pointers (`display_name`, `public_message`, `avatar_url`) released by `dashpay_profile_ffi_free` via `CString::from_raw`. The blast radius is worse here than in the array cases: three heap slots freed instead of one. Sibling profile getters in this same file already zero-initialize the output before fallible work; write `DashPayProfileFFI::empty()` immediately after the pointer checks so every subsequent early-return leaves the slot safely-freeable regardless of caller cleanup discipline.

In `packages/rs-platform-wallet-ffi/src/sign_with_mnemonic_resolver.rs`:
- [BLOCKING] packages/rs-platform-wallet-ffi/src/sign_with_mnemonic_resolver.rs:119-135: Silent in-place ABI change on exported dash_sdk_sign_with_mnemonic_resolver_and_path
  Reconciled STILL_VALID at bb02c416; the latest delta added the paired-invariant check inside this function but did not version the exported symbol. The `#[no_mangle] pub unsafe extern "C"` signing symbol grew two arguments (`expected_key_data: *const u8`, `expected_key_data_len: usize`) inserted between `network` and the output pointers while retaining its exported name. C symbols carry no ABI version, so any consumer linking against a pre-built xcframework or an external C consumer built against the previous prototype will still link and will pass the old `out_signature` pointer where Rust now reads `expected_key_data`, shifting every following argument. At a signing entry point this becomes type-confused arguments (a heap output buffer reinterpreted as read-only input data of caller-controlled length) — a memory-safety hazard rather than a clean link failure. Version the symbol (e.g. `_v2` / `_with_expected_key`) or keep the old name as a compatibility shim that passes `(null, 0)` internally, so stale linkage fails at load rather than mis-marshaling into a signing function.
- [SUGGESTION] packages/rs-platform-wallet-ffi/src/sign_with_mnemonic_resolver.rs:255-256: Bound expected_key_data_len before constructing the FFI slice
  The new binding check at line 255-256 calls `slice::from_raw_parts(expected_key_data, expected_key_data_len)` before the `match expected_key_data_len` at line 260 filters to the accepted lengths (20 or 33). `slice::from_raw_parts` requires the pointer to be valid for reads of `len * size_of::<T>()` bytes; a malformed FFI caller passing a valid pointer with a huge `expected_key_data_len` (e.g. `usize::MAX`) invokes UB at slice construction time even though the match arm would later reject it. The invariant added by the latest delta only enforces null↔0 correspondence, not length bounds. Reject unsupported lengths before forming the slice.

In `packages/rs-platform-wallet-ffi/src/identity_persistence.rs`:
- [BLOCKING] packages/rs-platform-wallet-ffi/src/identity_persistence.rs:62-162: IdentityEntryFFI grew in place (208→224 bytes) under unchanged identity persistence callback slot
  This PR appends `contact_profiles: *const ContactProfileRowFFI` and `contact_profiles_count: usize` to the exported `#[repr(C)] IdentityEntryFFI`, and the compile-time size guard (line 388) moves from 208 bytes on `origin/v4.1-dev` to 224 bytes at head. The `on_persist_identities_fn` callback name and vtable slot are unchanged. In-tree Swift is regenerated by cbindgen, so it is fine, but any external or stale consumer with the 208-byte header will stride the Rust-provided `Vec<IdentityEntryFFI>` as 208-byte rows: every entry after the first is misparsed from wrong offsets (owned string pointers read from what Rust now treats as inline byte fields) and the last row reads past the allocation. Because these are heap-owned string pointers freed by `free_identity_entry_ffi`, the failure mode is silent memory corruption at persistence time. Same class of concern as prior-7: version the callback slot (e.g. `on_persist_identities_v2_fn`) or the struct name so mixed-version linkage fails at load rather than silently mis-parsing.

In `packages/rs-platform-wallet-ffi/src/contact_persistence.rs`:
- [BLOCKING] packages/rs-platform-wallet-ffi/src/contact_persistence.rs:101-220: ContactRequestFFI grew in place (144→184 bytes) under unchanged persistence callback slot
  This PR grows `#[repr(C)] ContactRequestFFI` from the base 144 bytes on `origin/v4.1-dev` to 184 bytes at head (size guard at line 220), and `OnPersistContactsFn` gains additional trailing pointer/count arguments — but the callback remains in the same `PersistenceCallbacks.on_persist_contacts_fn` slot with the same name. A stale host callback compiled against the old prototype will still be installed and called; depending on ABI it will parse the upsert array with the 144-byte stride and either receive or ignore the trailing arguments, mismatching the Rust view. As with the IdentityEntryFFI growth and prior-7, this is silent mixed-version FFI mis-parsing at a heap-owned struct array. Version the callback slot/type so old consumers fail at install/link rather than mis-parse memory.

In `packages/rs-platform-wallet-ffi/src/established_contact.rs`:
- [SUGGESTION] packages/rs-platform-wallet-ffi/src/established_contact.rs:156-169: established_contact_get_note: null *out_note before fallible lookup
  Reconciled STILL_VALID at bb02c416 (unchanged). `established_contact_get_note` writes `*out_note = c_str.into_raw()` at line 167 only after handle lookup (162), note-presence (164-165), and `CString::new` (166) all succeed. Stale handles, missing notes, and interior-NUL failures leave the caller's `*mut c_char` slot unchanged, even though the success path returns an owned C-string that must be released with `platform_wallet_string_free` (`CString::from_raw`). The in-repo Swift wrapper zero-inits before the call so this is safe in practice today, but the FFI function should honor the defensive 'always safe to free' contract used elsewhere in this crate by nulling the pointer immediately after `check_ptr!`.